fetchPriority enabled by default in Firefox 132 #24518
Conversation
github-actions
bot
added
data:api 🐇
acreskeyMoz
force-pushed
the
fetch_priority_firefox
branch
from
c1a4e69
to
9632404
Compare
There was a problem hiding this comment.
In term of APIs, we also need to:
- update init_priority_parameter from
api/Request.json: https://developer.mozilla.org/en-US/docs/Web/API/Request/Request#browser_compatibility - add fetchpriority to
http/headers/Link.json: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Link#browser_compatibility - and in particular for early hints in
http/status.json: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/103#browser_compatibility
github-actions
bot
added
the
data:http 🚠
| @@ -40,6 +40,39 @@ | |||
| "deprecated": false | |||
| } | |||
| }, | |||
| "fetchpriority": { | |||
There was a problem hiding this comment.
@fred-wang This adds fetchpriority subfeature to 103 status. The values mirror those for the <link> feature - though for chrome this header wasn't implemented until 103, so I used that instead of 101 (which was the value used in link). Reasonable?
My understanding is that this header may be sent by a server prior to returning the final resource to indicate resources that the browser is likely going to want to request early. So basically this might be used to tell the browser to start loading a resource at higher priority before it parses the resource and finds the <link> tag that suggests it should do so - right?
There was a problem hiding this comment.
I'm not sure whether/when chrome or webkit implemented the 103 header, but yeah that seems reasonable.
I think your understanding is correct, but actually this is also true for e.g. 200 OK. The subtility here is that Early Hints can be sent before the final response has arrived, allowing resources to be loaded even earlier.
There was a problem hiding this comment.
Chrome implemented 103 preloads (Safari only supports preconnects in 103 now, where fetchpriority is not relevant so can probably be ignored for now).
It appears from the WPT's that you added that Chrome doens't error on fetchpriority on 103s:
https://wpt.fyi/results/loading/early-hints/preload-fetchpriority.h2.window.html?label=experimental&label=master&aligned
But we don't think it does anything special with it.
To us in Chrome it doesn't really make sense here as 1) high priority requests will be requested right anyway as soon as these are seen in headers and 2) low priority requests really shouldn't be sent in 103 requests. Not sure if Firefox was thinking of specific use cases for this that I'm not seeing? Or if it was just easier to support it everywhere rather than carve out an exception for link headers?
So you can argue it's "supported" in Chrome in that in that it won't error, but not sure if it's more confusing than useful to add in here?
CC: @pmeenan
There was a problem hiding this comment.
@fred-wang Can you comment on the point immediately above ^^^: Not sure if Firefox was thinking of specific use cases for this that I'm not seeing? Or if it was just easier to support it everywhere rather than carve out an exception for link headers?.
@tunetheweb My assumption here was that if a browser sees a Link header it would download it, but the priority would still be affected by settings like preload and fetchpriority. In otherwords, if you have a lot of stuff to download, the additional prioritisation hint is still useful. I'm pretty ignorant of this stuff, so hopefully @fred-wang can clarify what he things support means for a browser.
There was a problem hiding this comment.
I thinks supporting fetchpriority in 103 came after a review by @mb and I believed it turned out that implementing the generic support for Link header implied support for 103 too. In https://bugzilla.mozilla.org/show_bug.cgi?id=1882084 in addition to the basic test mentioned we also check that fetchpriority affects our internal priority in 103 header. But I don't think we had any specific use case in mind besides supporting what's the spec says. So I agree, probably documenting support for the generic Link header is the right thing to do...
| } | ||
| } | ||
| }, | ||
| "fetchpriority": { |
There was a problem hiding this comment.
Mirrors the <link> element for these features, which were added after introduction of LINK header. Ditto other subfeatures above. Assumption is anything that was implemented in link element is also in the header as per the docs. This is definitely true for fetchpriority on FF.
There was a problem hiding this comment.
If there is no support difference compared to <link>, I would suggest not to document these features here.
cc @Elchi3
There was a problem hiding this comment.
I think there are potentially differences- for a start, the Link header appears much more recently than the tag (thought that is captured), and more generally, there are things supported on the tag that are not supported via this header.
IMO it matches "policy" to document these as I have done.
Josh points out in discussion the bcd channel that just documenting the ones that come in different versions is confusing for users - i.e. his take is that once you have added one subfeature you should add all of them. I agree, but that also is against the policy.
Upshot, I don't plan to change this unless @Elchi3 or @queengooborg can confirm and update policy to reflect that.
|
@fred-wang I've added the extra information. Does this look sane to you? @Elchi3 Can I get this in before you do your monthly FF update please. |
There was a problem hiding this comment.
(Ignore this, I wasn't aware of Removal of irrelevant flag data.)
Instead of replacing the existing support statement, let's make this an array:
"firefox": [
{
// Previous statement
"version_removed": "132",
},
{
// New statement
}
],
Summary
We're enabling
fetchpriorityby default in Fx 132Test results and supporting details
https://bugzilla.mozilla.org/show_bug.cgi?id=1854077
Related issues
mdn/content#36121